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Protection against DOS attacks on smartcards 

1. state of the art 

t.t. Description 

5 One of the fundamental features of smartcard technology is the ability to act 
as a secure repository for various credentials (PINs\ keys, unblock codes* 
etc.). 

Currently, when credentials are verified by a smartcard for authentication 
purpose (i.e. when the smartcard tries to verify the identity of the entity 
10 requesting a service, such as a user, a temrtinal, a server, an administrator, 
or an application) an internal counter is decremented each time the 
verification fails. When this counter reaches zero, the associated credentials 
3fe blocked. 

iS 1.2. Probtem(s) raised ty stete of the art soiutlons 
1.2.1. Introduction 
Some credentials can be unblocked or reprogrammed (by entities having 
sufncient privileges), but others can't, and blocking them often results in a 
need to physically replace the smartcard. 

20 

For example, let's consider the iollowing scenarios (we assume that a file 
system smartcard is used, and the PIN is under the root directory of the 

smartcard): 

> If a user blocks his PliM, an administrator can unblock it with the unblock 
25 code 

> If both the PIN and the unblock code are blocked, a smartcard 
management system could ' repersonalize the smartcard using the 
transport key 

> If only the transport key and unblock codes are blocked, then the card is 
.30 still usatTte as long as the PIN" is not for^otten/btocked by the user and no 



' P^nional Identification Number, which in a secret code ^ped by the user to authenticote hinwelf 
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administrative operations are needed on the smartcard (loading of new 
file structures, etc.) 

> But if the PIN, the unblock code and the transport key are blocked, you 
must change the smadicard physically 

5 

1.2:2. DOS attacks 
Smartcards were not initieUly designed for use as security devices protecting 
personal computers (PCs) and networks Interconnecting those PCs. 
A family of attacks that is very relevant In such context (especially in 
10 corporate environments) has not been taken Into account when specifying 
smartcarcte features. 

One of the most popular and frequent attacks on the internet is the DOS 
(denial of ser/ice attack). This consists In attacking a component of the 
network (server, etc.). often by overloading it with requests. The component 
1.5 becomes unable to perform Its duties, and as a consequence the end users 
are stuck-The system is not compromised, but it is not usable anymore. 

If a virus hrts a big organization and tries wrong credentials until smartcards 
get blocked (e.g. by sending verify_key commands with random data), 

20 thousands of users would be unable to work. 

While end users' PCs can be recovered automatically thanks to backup 
systems, smartcards would need to be physically leptaced. During this 
replacement phase (which might be very long and costly for big 
organizations) users would be unkble to log on to their PCs and secure their 

25 network, or would have to do this With usemames and passwords which have 
a much lower security level tfian smartcards. 

1 .2.3. Key blocking at development stage 
One of the most frequent calls , to the technical support teams is due to 
30 smartcards that were accidentally blocked and cannot be programmed 
anymore. 
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t 

The technical supports need to figure out that the cards were actually 
blocked (people often think that there's a problem with the smartcard or with 
the smartcard software development tools that they are using). 
Then they have to supply the developers witti a new set of cards. 

5 

2. Invention 

2.1. Summary 

The idea consists in modifying the way the credentials' counter is managed. 
10 by adding a second counter, which works slightly differently. 

Once the first counter reaches zero, rather than blocking the credentials (as 

done currently), the smartcard starts decrementing the second counter. 

The second counter is associated with a waiting loop mechanism. 

Due to specific constraints of smartcard technology, the design of this waiting 
15 loop requires specific features that are part of the invention. 

Examples of such constraints: 

Smart^rds 

• T. 

> have no permanent clock 

> can be removed from the smartcard reader at any time by the user 
20 > can be remotely reset by an attacker at any time 

> have to comply with ISO 781 6 'standards 

> etc, 

2.2> Diagram 

25 The diagram displayed on the next page shows how the anti DOS 
mechanism can be put in place on standard ISO 7816 compliant smartcards. 

More details regarding the rules that should be followed when putting this 
mechanism in place are given In the following chapters. 

30 
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N.B. The same Idea could be implemented in other environments (e.g. USB 
tokens, etc.), in which case the rules might have to be adapted to the 
constraints of the new target. 

However, the basic principles described herein still apply. 
5 ; 

For the sake of clarity, the changes in the existing systems have been 
highliglited in red. 

Some components are added, but none are removed. 
Any component that Is not red is currently existing in state of the art 
10 smartcards. 



See figure 1. 

2.3. ' Description 
IS 2.3,1. Attempts counters 

As described In 2.1, the existing attempts counter is kept, and it is 
complemented with a second attempt counter. 

The first counter is unchanged (usually such a counter has an initial value 
20 varying between 1 and IS). Most often, the counter is predecremented before 
each credentials verificatton. If the verification succeeds, the counter is reset 
to its maximum value, othenvise it is unchanged. 

The second counter (the new one) starts being decremented only after the 
25 first counter reaches zero. When the first counter reaches zero, it is no more 
decremented, but the credentials are not yet blocked, instead, the second 
counter Is predecremented before each new credentials verification. If the 
presented value was good, both counters are reset to their respective 
maximum values, otherwise th^y are unchanged and a waiting loop is 
30 f)erformed. if the second counter reaches zero, the credenUais are btocked. 



The initial value of the second counter is discussed in 2.3.7. 
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2.3.2. Waiting loop counter and waiting loop flag 
A waitiny loop counter and a waiting loop flag are managod in EEPROM (or 
in any avaulable programmable non-voiatile memory). 
5 Both have a global scope. I.e. they remain visible outside the context of the 
waiting operation and of the credentials verification. 

The flag is initially cleared, while the initial value of the counter is discussed 
irr2.3.7. 

There's only one waiting loop counter and one waiting loop flag for the 
smarlcard, while the number of attempts counters is proportional to the 
number of credentials on the smartcard. 

15 2.a3. Waiting loop 

The waiting loop consists in: 

1. Setting the waiting loop flag 

2. Spending a predefined amount of time» for example by performing a 
. series of NOP (no operation, i.e. dummy instmction), not exceeding the 

20 maximum duration negotiated 'thanl<s to the ATR (Answer To Reset) since 
we don^t want to time out 

3. Informing the host tiiat the siYiartcard is alive (i.e. it has not timed out). 
Following ISO 7816 constraints, this consist in sending a specific byte to 
the host (the value $60 to be more accurate) 

25 4. Decrementing the waiting loop counter, and if it is non zero going back to 
step 2" 

S- Resetting the waiting loop counter to its maximum value 
6. Clearing the waiting loop flag . 

30 Note: alternative means can be used instead of the waiting loop counter (e.g. 

If^the-chlp^Ttasa timer available), but tiie principle of tiie waiting loop remains 
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the same.- In any case, a marker indicating the current level of completion of 
the loop needs to be stored in non volatile memory. 



2.3.4. Resuming the waiting loop 
5 The waiting loop can be interrupted, either accidentally or on purpose. 

For example, the end user might wonder what's happening with his 
smartcard and remove it from the reader, or an attacker might want to block 
the credentials quicker and send a reset order to the smartcard in order to 
stop the waiting loop mechanism. 

10 

In order to prevent this, the waiting loop status (counter and flag) has a global 
scope (as explained in 2.3J2), and a component of the smartcard (the APDU 
managor) is modified in order to resume the waiting operation in case It was 
interrupted during a previous session. 
15 This mechanism is described more in details in the next section (2.3.5). 

2.3.6. APDU manager modification 
Currently, when a smartcard is reset, It performs a certain number of 
operations (various tests, selection of the communication protocol, of the 
20 voltage for the power supply, of the communication speed, etc.) then If 
everything Is OK H switches to a, mode where it can leceive oidei« from the 
host. 

Those orders are called APOUs (application protocol data units). 
The piece of software njnning on the smartcard and responsible for receiving 
25 APDUs from the host and dispatching them (either to the smartcard operating 
system, to the applets that have been loaded, or to any relevant module) Is 
called the.APDU manager. 

The APDU manager has to be mbdified in the following manner. 
Before an APDU is dispatched, the APDU manager has to check the state of 
30 the waiting loop flag. 

In case the flag was cleared, everything works as before (l.e. the APDU is 
processed normally by the smartcard). 
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Otherwise, it means that a waiting:loop has been interrupted and needs to be 
resumed. 

The APDU manager calls the waiting loop mechanism described in 2.3.3. 
Since the waiting loop counter Is stored in non-volatile memory and has a 
global scope, the waiting loop continues where it had previously stopped. 
In case the waiting loop is interrupted again, it will be recovered thanlcs to the 
same mechanism. 

* 

Only when the waiting loop has been completely performed will the APDU 
manager start processing the APDU that was called. From the external world, 
The smartcard wilt behave exactly as before except that the execution of the 
APDU will take much longer than it does normally. 

Optionally, certain APDUs (such as diagnostic APDU) can be allowed prior to 
the waiting loop. C,F. 2.3.9 for more details. 

The reason for performing the waiting loop in the first APDU that is sent to 
the smartcard is twofold. 

> Rrst, ffie waiting loop needs to be compliant with ISO constraints and 
must be transparent to the existing systems (no update on the client 
software should be mandatory in order to deploy the DOS protected 
cards). The waiting loop cannot happen at any time (if ifs done just after 
reset, the smartcard might belconsldered as not worldng). Also. Windows 
2000 and XP power down the smartcard when no connections are made 
during a certain time, which Justifies informing the host that the smartcard 
is alive and processing (thanlcd to the procedure described above). 

> Second, this waiting loop serves a& a protection avoiding that the 
credentials be blocked, but It also has to warn the user that an attack (or a 
bug, in case it happens ajt development stage) is threatening the 
smartcard. So in order to be noticed, the waiting loop must occur at a time 
when the smartcard is expected to perform certain operations and return 
a result. 
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2.3.6. Types of credentials for which the invention is relevant 

The invention is potentially applicable to any kinds of credentials, however it 
is more secure and useful on certain than on others. For this reason the 
parameters tuning discussed in 2.3.7 will be adapted to the type of 
5 credentials you deal with. A more detailed discussion on the security impact 
of the invention depending on the type of credentials can be found in 2.3.8. 

2.3.7. Parameters tuning 
Two paran>eters need to be fine-tuned: 

10 The duration of the loop and the ma}dmum number of slowed attempts. 

The first one Is proportional to the waiting loop counter (and is unique for the 
whole smartceuxl), while the second Is directly linked to the new number of 
attempts counter introduced In this invention (and can be different for every 
credentials). 

15 Several conflicting constraints determine the best value for those parameters. 
Some of those are listed below: 

> The maximum number of slowed attempts multiplied by the duration of 
the loop should be long enough to render the DOS attack success very 
unlikely 

20 > The maximum number of slowed attempts should be small enough to not 
increase the likelihood of credentials guessing attacks (see chapter 2.3.8) 

> The duration of the loop should be long enough for the user to notice that 
something is going wrong and.-report it to tiie helpdesk 

> The duration of the loop should be short enough for the users not to be 
25 blocked too long during their work. Indeed, although thte state is 

temporary (and does not require any inten/ention on the smartcard in 
order to come back in a normal state), it is inconvenient 

> Etc. 

30 As an example, a waiting loop bf approximately 30 (thirty) minutes and a 
maximum number of ICC (one hundred) ^owed attempts seem to be 

i 



1 



uc re9U de : 33 1 47 46 7B 26 



SCHLUHBERGERSESm 

i 

9 



24/^10/02 16:40 Pg: 15 



reasonable parameters for a transport key. for open platform keys, and for 
unblock codes. 

Assumption: the above keys and codes need to be strong (i.e. chosen 
randomly or cryptographicaily. by a diversification mechanism etc.). 

5 For PIN codes, the maximum number of attempts should be much lower, for 
example 5 (five), unless a very robust PIN policy has been defined and 
enforced, C.F, 2.3.8. This increases the probability (which remains extremely 
unlikely) of a successful DOS attack on the PIN, but such attack could be 
recovered without changing the smartcard physically and does not represent 

10 a significant threat 

Of course the actual values can be customized at personalization stage 
according to the exact applk»tion and security requirements. 
The smartcard OS should prevent those parameters from exceeding the 
IS limits that guarantee a proper level of security (it is usually the case today for 
existing counters, which most often cannot use the full range of values 
allowed in a byte but are limited to the first nibble). 

2.3,8. Security concerns 
20 The mechanism that is proposed in this invention Is designed in order not to 
lower the Security of the smartcard with regard to other kinds of attacks. 
It comes with certain prerequisHes (which are compulsory for smartoard 
security anyway). 

t 

25 For example: ; 

1. The counters shouM be predecremented (as described above), or a 
flagging mechanism should be put in place in order to prevent tearing 
attacks and the like 

2. When applicable, challenge response should be preferred to credentials 
.^0 comparison 

3. In case direct credentials corhparison is required (e.g. PIN verification), 
the credentials bits should be verified in random order, and optionally 
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should be XORed with random, in order to prevent SPA attacks and the 
like 

4. Credentials should be as unpredictable as possible (this is easily 
achieved with transport keys which can be obtained by diversification of a 
randonrj master key for example) and the smartcard OS should enforce 
that the maximum number of slowed attempts be small enough even for 
such credentials (e.g. < 256) ' 

5. For credentials that are potentially predictable (e.g. when they are not 
defined by the system but by the user), a proper security poltoy should be 
enforced. For example, the PIN should follow a PIN policy in older to 
avoid trivial and predfetable PIN values, and this can be enforced within 
the snrfartcard when possible (e.g. Schlumberger middleware applet does 
It), In order to prevent PIN guessing attacks 

6. Etc. 

The third point is important due to the fact that the number of attempts is 
Increased. which means that the likelihood of a power analysis attack success 
is greater if such a countermeasure is not in place. 

c 

The fifth point is important because due to increased number of attempts, the 
bnjte force attack (which is ineffective on random credentials) could be 
replaced by a much more efficient attack In case there are poor PiNs (so 
poor PINs should be rejected, more than ever). Again, the initial value of 
PINs' second counter shall be much lower than with * unpredictable 
credentials, as stated In 2.3.7. 

Provided the basic security guidelines are respected, the security of the 
smartcard should be Improved regarding DOS attacks (the smartcard is no 
more vulnerable), while not lowered regarding existing attacks. 
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2.3.9. Opttonal notification to the external world 

Optionally, a command could be implemented on the smartcard in order to 
notify the external world that a DOS attack (or wrong manipulation) is 
undenway. 

3 Th© APDU manager could let this command execute without applying the 
delay loop (the delay would apply to the next command anyway). 
Diagnostic tools could poll this command in order to check what's going on. 
The smartcard would reply with a status word SW_DOS_UNDERWAY or 
$9000. 

10 Another APDU command woiild be necessary in order to let the 
administrators reset the DOS.UNDERWAY flag. 

2.3. 1 0. Impact oi the optional notlficatton on the external world 

The client application does not have to be modified, which is one of the 
15 benefits of this invention. Only the administrative toots (CMS, personalization 
tools, etc) need to be updated, but not the software ("client application") that 
is rolled out on each end user's PC. 

However, in order to be more user friendly, the new behavior of the card 
20 could be taken Into account in the client application and an explicit warning 
message could be displayed to the user, thanks to the notification command 
descrit>ed in 2.3.9. The client application could then send a "dummy" APDU 
such as a Select_root that would potentially trigger the waiting loop. If there's 
indeed a waiting loop, the client application could detect It and notify the user 
25 that the card is temporarily unavailable. Otherwise normal processing would 
proceed. 

Without such a modification in, the client application, the end user will 
experience a temporary DOS: the client application will be blocked during the 
30 predefined time (for example 30 minutes, as discussed in 2.3.7). which will 
Info.'Tn him that something wrong is going on. 
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In terms of security, it should make no big difference. It would just be less 
user friendly. After a while, the user would contact some helpdesk, which 
would quickly diagnose the DOS attack. Since the attack is likely to be rare 
(provided .we implement the described countermeasure), it shouldn't be an 
5 issue, and modifying the client application is not necessarily worth tfie 
Investment. Especially when considering that the virus could circumvent this 
notification and hide it to the client application and to the end user. 

2.4. Alternative possibilities to prevent the Credentials blocking 
10 One can wonder whether there are alternative means to prevent the attack 
from happening, that wouldn't necessitate any changes in the smartcard. 
Unfortunately, It seems that such options do not exist. 

Some could think of presenting the credentials through a secure channel in 
IS order that' no forbidden program (virus etc.) tries to verify credentials (with 
potentially wrong values that could lead to a card btocking). But how do you 
open the secure channel in Vne first place? Precisely by authenticdting to the 
card through a s uccess f u l creder jtials presentatk}n... So tills first step is still 
subject to the attack. Anyway, sWure channel keys are stored In the PC, 
20 while by definition the PC is not secure enough and can be compromised by 
a vims (othenvise we would store all smartcard's secret contents such as 
RSA private keys in the PC and wouldn't use smartcards as security tokens 
anymore). 

25 This meaos that even when secure channels aie used for protecting -certain 
credentials presentations, a virus .can block the credentials: 

> it can prevent tlie secure channel from being usable (e.g. by blocking its 
keys) 

> and/or it can find tricks to use the secure channel iliegitimately (e.g. by 
30 hacking the secure channel keys in the PC) and block the credentials 
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2.5. Example of behaviour of an attaoked system 

Let* s consider a typical corporate badge customer, such as an organization 
with 10,000 employees equipped with PKI badges. 

Let's suppose that a virus (e.g. sent to the employees In an e-mail 
5 attachment) hits this organization,: and that this vinjs consists in blocking the 
badges' credentials by presenting wrong values. 

Without the invention, the virus could quickly (it's a matter of fractions of 
seconds) erase the first counter (by a few wrong credentials presentations). 
All 10,000 users could be quickly blocked and would have to change their 
10 badges. As described in 1 .2.2, this could have a very significant financial and 
security impact on the organization. 

Now lef s examine what happens When the invention is implemented. 

As today, the virus could quickly erase the first counter (by a few wrong 
15 credentials presentations). 

However,. as soon as the second counter starts being decremented, the 

-waiting iot^ mechanism makes It very long for the virus to erase the counter. 

and the user is very quickly awar^ that his badge is being attacked. 

even if the client application does not notify the user that an attack is 
20 undenvay, or if the virus inlerceijts the notification and prevents the client 

application from noticing it. the user will experience a temporary DOS. 

As stated in 2.3.7. the smartcards oould be personalized to wait 30 minutes 
after each additional wrong attempt, and wait 100 wrong attempts before 
25 blocking the credentials. 

tWs means that during thirty miriiules, the user will be unable to perform any 
smartcard-retated actions such a$ 

> logon to the PC through Kerberos 

30 > opening a VPN connection with Check Point 

> decrypting files on the hard disk using Entrust ICE 

> signing e-mails in Outlook 
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> unlocking the screen saver with the GINA 

> connecting to a secure web server in SSL through Netscape 

> etc. 

5 To be more accurate, the user cai;i initiate any of these tasl<s, and in theory It 
will work but It will take 30 minutes longer than usual (during 30 minutes, the 
card keepis sending a specific ISO byte, which tells the PCSC stack that it Is 
still processing and that the reader should not time out). 

10 This also means that before blocking the credentials In question, the user 
should experience 50 hours of DOS per credentials (100 times 30 minutes) 
without noticing anything abnomnal. 

Since actually bk)Cking the card usually means blocking a PIN. a PUK and a 
15 key (C.F. example in 1.2.1), bidcking the card requires above a hundred 
hours of DOS. 

■ 

It also requires that-the^ virus is Intelligent enough to imercept all legitimate 
credentials verifications. Otherwise the counters are reset to their maximum 
20 value, and the delay (more than lOO hours) restarts from the beginning. Such 
a vims feature cannot be guaranteed to work in all situations over such a 
long period (the smartcard could be plugged in another PC that is not 
Infected by the virus, and the card could be unblocked by accident...). 

25 Typical use of corporate badge consists in carrying the badge with you. 
which means that it Is unplugged from the PC as soon as you leave your 
desk (In order to open the doors, pay the cafeteria, access the parking lots, 
etc.). • ; 

30 Only when the user is in front of his PC with the smartcard connected can the 
vims attack the credentlais. Let's make the assumption that employees 
spend an average 5 hours a dayjn front of their PC (which is a lot, as it's an 
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average for every employees and for every day of work), and that the 
smartcard is plugged all this time. Even with this pessimistic hypothesis, the 
virus needs at least one full working month before blocking the card (this 
corresponds to the shortest possible delay oomputod in the previous page, 
5 which was above a hundred hours). 

It is completely unrealistic that users spend more than one month without 
being able to access any services linked to smartcard (and quite often this 
Includes the inability to use the PC at all. since corporate badges are usually 

10 used to login to the PC) without reporting any problem to the helpdesk. 

This is extremely unlikely to happen, as It would mean that the users don't 
depend on their smartcards and don't use it (In which case the attack does 
not really affect them, and they can most likely wait a few days or weeks 
before their badge is replaced). 

15 But if users don't actually us© their badge, there's no reason for thorn to plug 
it in their PC, which in fact prevents the virus from attacking it (the card needs 
to be connected in order for the DOS to take effect)... 
It is even more unrealistic that all of the 10,000 employees are unable to 
access the services secured by the smartcard during more than one month 

20 and don't report anything. 

What will happen Is that at least one employee will call the helpdesk, saying 
that the client application displayed a message such as "your smartcard is 
under DOS attack, your PC must' be infected by a vims, please contact your 

25 helpdesk and update your antivirus'' or simply complaining that the smartcard 

i 

does not work. 

•J 

The helpdesk can analyze the smartcard and verify that there's a DOS attack 
(thanks to. the diagnostic APDU, or just by verifying credentials with a wrong 
30 value and checking if if s already in slowed state). 
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As soon as th© hefpdesk finds a single user with the probtenrt it could check 
some other users at random, and if it notices that a few of them are also 
Infected it should apply an emergency plan for the whole organization, for 
example ask employees to unplug the card from their reader until an antivirus 
5 update is available and is successfully run on the PC (and optionally connect 
to a kind of SSM and perfonm authentication with all relevant credentials in 
order to reset all counters to their max value). 

30 minutes maximum after the antivirus cleaned the PCs, an badges will be 
10 in working order. 

If a few users were to be blocked anyway (which is almost Impossible), It 
wouldn't be an issue, their badges could be replaced. 
The real issue would be that a high number of users are blocked, and 
15 massive quantities of new badges need to be produced and personalized, 
but this can't happen anymore with the suggested countermeasure. 

Anyway, the simple fact that there's a countermeasure should render this 
attack very unlikely to happen (no more motivation for the attacker). 

20 

2.6. Target Applications ' 

The main target for this invention consists of applications built around 
corporate badges. 

However, the Invention is potentially applicable to any type of smartcard and 
25 for any application. 

3- Solution^fi\ brouQhf by the invention 

Massive smartcard destruction by DOS attacks is made much more difficult. 

30 

Problems* linked to smartcards blocked accidentally by smartcards 
application developers are significantly reduced. 
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4. Applicability of the invention 

The invention is applicable to any. microprocessor smartcard, and potentially 
to other kinds of hardware tokens. 
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Claims 



1. Smartcard comprising a counter wheroin the smartcard also comprises an 
5 antenna. 
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